The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
In packet-switched networks consisting of multiple network elements such as routers and switches, an on-path signaling protocol such as Resource Reservation Protocol (“RSVP”) may be used to reserve routing paths for the purpose of providing optimized routing of specified kinds of network traffic, such as voice traffic. RSVP is described in Braden et al., “Resource ReSerVation Protocol (RSVP)—Version 1, Functional Specification,” Request for Comments (RFC) 2205 of the Internet Engineering Task Force (IETF), September 1997. In general, RSVP can be used to reserve resources in order to achieve a desired quality of service (QoS) for a particular kind of traffic. Resource reservations established using RSVP messages expire over time unless the reservations are refreshed.
RSVP defines sessions and flow descriptors. A session encompasses a data flow that is identified by its destination. A flow descriptor is a resource reservation that encompasses a filter specification (filterspec) and a flow specification (flowspec). When the reservation is implemented at a router, packets that pass a filter defined by the filterspec are treated as defined by the flowspec. RSVP operation is controlled using Path messages and Resv (reservation) messages.
In general, RSVP operation at a host such as a router proceeds as follows. A sender issues a Path message; a receiver receives the message, which identifies the sender. As a result, the receiver acquires reverse path information and may start sending Resv messages to reserve resources at intermediate hosts. The Resv messages propagate through the Internet and arrive at the sender. The sender then starts sending data packets and the receiver receives them.
In some cases, the only paths existing between the sender and receiver contain one or more firewalls. In order for data packets to pass through a firewall, the firewall might need to be configured to allow a certain class of data packets of pass through the firewall; the firewall's policy might need to be changed. For example, the firewall's policy might need to be changed to expressly allow data packets that originate from the sender's Internet Protocol (IP) address to be forwarded to devices that lie on the other side of the firewall from the sender.
However, firewalls are implemented for a good reason: to keep unauthorized data flows from invading portions of a network. If the general public were permitted to alter the firewall's policy, then the purpose of the firewall would be defeated. Only certain entities should be allowed to alter the firewall's policy. If a firewall is to remain sound, the firewall must require some proof that each entity that attempts to alter the firewall's policy is actually authorized to do so.
In theory, the firewall could use an authentication system like Kerberos to authenticate each entity that attempted to alter the firewall's policy. However, such an authentication system would be separate from RSVP. If Kerberos were used in conjunction with RSVP, then both RSVP messages and Kerberos messages would be passing through the network. Available network bandwidth would be reduced. Furthermore, because of the separate nature of the RSVP and Kerberos protocols, there would be some delay between the RSVP resource-reservation operations and the Kerberos authentication operations. A significant amount of time might need to pass between the time that the sender begins using RSVP to reserve resources along a path, and the time that the sender can begin sending data packets along that path. Implementing a solution that used multiple separate protocols for different purposes would be complex and require a high degree of skill and organization.